如何成为开源社区commiter

作者还不是任何开源项目的commiter，只是个一名普通的kylin社区贡献者。

原计划是自己成为社区commiter后，再来写类似的话题。

但昨天（本文写于7-16号）听了文嵩老师在“开源中国开源世界”高峰论坛线上的开源主题演讲，很受鼓舞，决定提前把自己的想法写出来，抛砖引玉的同时，自勉。

本文综合了众多开源社区PMC，commiter，贡献者的经验心得，以及自己的一点实践经验，希望能对大家有帮助。欢迎大佬们留言自己的心得体会，感激不尽。

你为什么想成为commiter

跟kylin社区的PMC Chair聊，如何成为社区的commiter。他反问我，你为什么想成为commiter呢。

他见过太多人为了贡献者身份，加代码注释，改文档语法错误，刷PR。也见过40个PR的贡献者成为commiter后，没有贡献了。

社区鼓励一切贡献行为，提交注释，修改语法错误都是值得肯定的，也愿意给杰出贡献者授予commiter甚至PMC作为辛勤付出的奖励。但社区希望commiter身份不只是一种里程碑式的奖励，更是一种对未来的，继续共建社区的期许。能力越大，责任越大。就好像我们在工作中做出杰出贡献，可以收获丰厚的年终奖，这是对过去贡献的奖励。但并不意味着一定能晋升，因为晋升一般伴随着委以重任，是对你未来继续贡献的期许。

那么我们为什么想成为commiter呢？

诚然，commiter身份可以让我们身价倍增，技术影响力提升。但commiter身份和技术影响力的关系似乎是个先有鸡还是先有蛋的问题。究竟是commiter身份给了我们影响力，还是因为有了影响力，我们被认可了与之相配的身份？

PMC认为是后者。因为做的贡献，因为技术影响力，我们被认可了，才有了PMC提名，激励我们做更多的事情。

开源，是为了更好地改变这个世界。commiter的身份，是为了让我们的努力可以惠及到更多的开源使用者。

如何起步

贡献者如何起步，说法很多。有多加注释刷PR的，有勤回邮件混个脸熟的。还有个大佬，让我夜深人静的时候多看看其他人的PR提出优化建议......

这就是小马过河，每个人的情况不同，要找到适合自己的路。

我个人认为，贡献首先要有业务价值。因为有业务价值，才需要改变，才具备了优化价值。将价值贡献给社区，就有了影响力。影响力大了，自然就有人邀请你做分享，影响力进一步扩大。于是commiter就是水到渠成的事情了。

所以，首先要将开源产品用起来，产生业务价值。当现有功能满足不了业务需求时，后续的一切，就自然而然的发生了。

代码通用性原则

俗话说得好，Don't say， show me the code.

业务代码贡献给社区的最大阻碍，就是业务代码往往有特定的背景，经常是一锤子买卖，不具备通用性。而要贡献给社区，需要我们想清楚业务背后的通用逻辑,用通用逻辑实现我们的业务，对我们的成长很有好处。

现在举两个例子。

第一个例子。kylin启动脚本，有个逻辑，判断hive环境是否已经可用，并从hive客户端输出中，解析出hive jar的绝对路径。由于这个逻辑会启动二次hive客户端，在公司环境大概要运行1分钟，影响服务启动速度。要提速，可以这么改：

    #source ${dir}/check-hive-usability.sh
    #hive_env=`hive ${hive_conf_properties} -e set 2>&1 | grep 'env:CLASSPATH'`
    hive_env=`cat ${dir}/hive-cli.txt`

注释掉的是社区代码，修改为直接读文件的方式。让运维直接把jar的绝对路径信息写到hive-cli.txt文件里面。

但如果hive安装路径变了，安装的版本变了，就要重新准备一个hive-cli.txt文件，体力活。

从通用性角度，可以这么改：

 36     if [ ! -f ${dir}/hive-env-classpath.txt ]
 37     then
 38         echo "init hive env classpath"
 39         source ${dir}/check-hive-usability.txt
 40         hive_env=`hive ${hive_conf_properties} -e set 2>&1 | grep 'env:CLASSPATH'`
 41         echo $hive_env > ${dir}/hive-env-classpath.txt
 42     else
 43         echo "load hive-env-classpath.txt"
 44         hive_env=`cat ${dir}/hive-env-classpath.txt`

先判断记录classpath文件有没有。没有就说明服务是第一次启动，验证hive环境可用，并初始化classpath文件。后续再次启动就可以直接加载文件了。如果要升级环境，升级脚本加一步删掉claasspath文件，就又可以自动验证hive环境，加载jar绝对路径了。

这个PR提交给了社区，但社区已经有了类似的实现。说明提交PR要抓紧啊。

再来看另一个例子。拓展kylin能力边界，将构建的运行结果发给kafka，以解耦kylin和第三方调度系统的联系，降低轮询对系统的负载。公司代码库里的配置长这个样子：

18 kylin.engine.xiaoju.kafka-enabled=true
19 kylin.engine.xiaoju.kafka.clusterId=xxx
20 kylin.engine.xiaoju.kafka.topic.name=xxx
21 kylin.engine.xiaoju.kafka.appId=xxx
22 kylin.engine.xiaoju.kafka.password=xxx
23 kylin.engine.xiaoju.kafka.bootstrap.servers=xxx

为什么配置路径有xiaoju呢？因为公司的kafka用了gateway，kafka参数配置跟社区原生的不太一样，特地声明支持的是公司版本。那这个功能要怎么提交给社区呢?

首先，配置里面不能带xiaoju。其次，kafka的参数需要通用化，既可以指定必选参数，也可以指定可选参数。修改思路如下：

增加kylin.engine.job-status.write.kafka=true，启用该功能。
配置kylin.engine.job-status.kafka.bootstrap.servers=xxx，指定连接服务地址。
kylin.engine.job-status.kafka.topic.name=xx，指定发送topic名。
其他需要的kafka配置，可以通过kylin.engine.job-status.kafka.{name}={value}配置，kafka的Properties配置会增加所有的{name}={value}的配置。
提供一些默认值：
ACKS_CONFIG=-1,
COMPRESSION_TYPE_CONFIG=lz4，
RETRIES_CONFIG=3，
LINGER_MS_CONFIG=500，
BATCH_SIZE_CONFIG, 10000

这个PR刚被社区接收，KYLIN-4612。

通过这两个例子，我希望大家能了解什么是社区认可的通用性，如何设计我们的代码，如何同时满足业务需要和通用性原则。以及，尽早提交

善用工具

曾经，我MAC本地放了两份kylin代码，一份远程库连公司仓库，一份远程连fork社区的个人github库。如果要把社区新版本的patch打到公司库里，或者给社区提交PR，要在两个代码库之间手工拉diff，做合并，一旦有冲突很麻烦。现在，学会使用git自带的功能，在多个仓库间切换。工具就是生产力，要善用git工具。

下面分享一下提交PR的流程。

假设这个功能已经在公司环境得到验证。首先应该和社区讨论一下这是否是一个通用问题，之后提交自己的jira，生成jira id。

之后拉取社区master的最新代码。git  remote add可以添加多个仓库，一般一个公司的仓库，一个社区的github地址，一个自己fork社区的github地址。用git fetch repo branchID可以刷新某个远程库的指定分支，一般只需要拉取社区的master分支。

从git log中找到自己要提交的commit id，切到社区maste分支，checkout -b KYLIN-XXXX在本地切出要提交PR的分支，用git cherry-pick commitID合并公司库的提交，解决冲突，进行测试。

测试通过后，git rebase 合并commit，修改注释，提交到自己的github fork库。再去社区github上建个PR，提交工作就完成了，可以联系commiter review了。

还有一个小技巧。一般github注册的都是个人邮箱，而公司库的提交使用的是公司邮箱,邮箱信息不一致。可以把公司邮箱设置为github账户的第二邮箱，这样就不需要修改commit里的邮箱信息了。当commiter merge PR时，能够自动关联你的github账户，记录在你的个人贡献里。

提高影响力

有了一些PR贡献，可以考虑进一步提升自己的影响力。怎么提升呢？

影响力就是让你的贡献可以被更多人知道，产生更多的价值。

可以加入用户群，开发者群，一起解决发现的问题。

可以订阅用户邮件组，开发者邮件组，jira邮件组，每天或每周关注下现在大家在讨论什么问题，有什么新的jira，commiter review时关注哪些点，跟进社区前进。

慢慢的，圈子内会有一定的知名度，可能会被邀请参加一些会议做分享，进一步提升自己的影响力。

提高英语水平

参与开源，英语很重要。

虽然kylin是个华人主导的社区，虽然大家可以在微信群里用中文交流，甚至可以用中文提jira。但流利的英语听说读写，还是非常有必要的，因为影响力并不仅限于国内，是国际化的。举个反例，前两天，受邀参加一个线上的北美kylin meetup做分享。但由于英语口语不行，只能谢邀婉拒。

如果有免费方便的英语口语线上资源，请留言~

建立联系

我们可以埋头刷贡献，期待被伯乐慧眼识博。也可以主动出击，和PMC和commiter保持沟通，建立联系。毕竟影响力还是要通过影响他人体现的。

以受邀成为apache commiter的通用流程为例。需要一个社区PMC发起提名，3个社区PMC投+1票。那么你至少应该跟4个PMC建立联系，和他们交流对贡献，影响力的认知看法。剩下的就是用心耕耘，一切交给时间。

以上就是我关于如何成为开源社区commiter的心得体会，感谢阅读。